hello~
ive been around psp's for a while and im getting interested with homebrew apps on them (i have a 3001). anywho, im a pretty decent delphi/pascal coder but i haven't ever used C, and it appears that's the only language that works on psp's right? just to clear things up, psp's will run foreign code fine it just wont launch it, that's why you run homebrew through legit psp games with exploits right?, and the reason we cant run homebrew is because our homebrew isn't kirk-signed right. (kirk is...? hardware? what?)
now, game/buffer overflow exploits are usermode, how would i go about finding kernel exploits, how would i even start to look for them? one last question, how did Pandora's battery put psp's into service mode, and how the hell did he come up with that idea? (do psp 3000's even have a service mode? or is it gone completely?)

:D

Kirk is hardware. Kernel exploits are exploits found in the vsh, they will most likely be found in formats such as mp3, tiff, png, mp4 ect. Pandora battery's were originally created by Sony, they used it as a shortcut to reflash and bricked psp, I'm not sure how hackers cracked it, but its in a vid somewhere on this forum, and no service mode didnt' disapear on the 3k or the GO, sony just change the ipl and pre-ipl so our magic memory sticks won't work...

and we cant dump the pre-ipl why?

Kirk is hardware. Kernel exploits are exploits found in the vsh, they will most likely be found in formats such as mp3, tiff, png, mp4 ect. Pandora battery's were originally created by Sony, they used it as a shortcut to reflash and bricked psp, I'm not sure how hackers cracked it, but its in a vid somewhere on this forum, and no service mode didnt' disapear on the 3k or the GO, sony just change the ipl and pre-ipl so our magic memory sticks won't work...

Err... Kernel exploits are found... in the kernel.

Err... Kernel exploits are found... in the kernel.

Yes I know but when you are in the vsh you have access to the kernel, so if you find an exploit in the vsh then you have a kernel exploit, right?

and we cant dump the pre-ipl why?

Because by the time we can load code to read it, it's gone and the ram has been reallocated. The preipl *was* dumped using other, more exotic methods (UPNand voodoo magic).



Err... Kernel exploits are found... in the kernel.

Yes I know but when you are in the vsh you have access to the kernel, so if you find an exploit in the vsh then you have a kernel exploit, right?

The reason VSH exploits are desirable is because they are normally portable media based, this means that users don't have to go out and buy a game in order to execute their exploit, take ChickHEN for example, that utilised a TIFF file exploit and was as simple as placing the image in the appropriate directory along with a binary file in the root of the MS. Also, I think you can take what Mathieulh says as pretty much gospel in these kinds of topics.

one last question, how did Pandora's battery put psp's into service mode, and how the hell did he come up with that idea? (do psp 3000's even have a service mode? or is it gone completely?)

Tyranid's speech at the CCC answers partly to this question:
http://video.google.com/videoplay?docid=-993960164729227655#

Also any subject involving "nem" on ps2dev.org is likely to have partial answers to this. Here is an explanation by nem himself:
http://webcache.googleusercontent.com/search?q=cache:XE7yrXR_6rYJ:forums.ps2dev.org/viewtopic.php%3Fp%3D57634+site:forums.ps2dev.org+n em+service+mode&cd=1&hl=en&ct=clnk&gl=us

(Sorry, giving you google's cached version because ps2dev seems to be down a lot recently :( )

...., and no service mode didnt' disapear on the 3k or the GO, sony just change the ipl and pre-ipl so our magic memory sticks won't work...
(i read and watched the links wololo posted,)
@some1: so service mode still exists we just can't get to it, (right?); sony can, so its gotta be possible.

[thinking out loud]

lets assume sony gets a broken(flash) psp (3001).
lets also assume sony made it easy to fix (eg. don't need to open it up).

possible ways to access it (IO stuffs):
1:usb
2:-wireless
3:memorystick
4:-audio/headset plug/video
5:-power plug
6:-umd
7:battory

if the flash is dead so im guessing wireless, UMD, audio/video are out, and you cant really do anything with the power plug.
okay that leaves us with usb, battery and memstick (who would have guessed?).
[/thinking out loud]

its pretty safe to say that sony still uses some type of battery to get into service mode right?

I imagine it's a memory stick combined with something else. Don't forget there is also the serial port (where the video out connectors are).

However, even if we can get into service mode we still have the ipl signing issue.

i think it's usb+memstick

If it's USB, then Pre-IPL should have been changed to include a small USB driver -or load it from flash, but since flash may have been wiped out, it makes not much sense-. does the storage for Pre-IPL allow the inclusion of a whole USB driver?

Doesn't necessarily need to be a driver. syscon could just detect a signal on a pin - not necessarily a full usb connection. After all, the pre-ipl for slim and fat don't have any battery reading code - they simply detect something set by syscon.

When that has been done, service mode could probably be completed using a memory stick, similar to what is done with the battery.

there was a thread on service mode for 3k/go earlier.. he said usb+ms. they ran into trouble with the msid and msipl not matching. however they could have just been a troll..

as far as i know, you can execute c/c++, basic, lua, delphi, python... i think thats it

as far as i know, you can execute c/c++, basic, lua, delphi, python... i think thats it
you can execute delphi on a psp? (thats great news for me :D) umm, how? there is no delphi-pspsdk.
[edit]
okay so i read up about datels lite blue thing and it does indeed put 300x's into service mode you just cant do anything from there. so that kind of answered one of my q's.

Doesn't necessarily need to be a driver. syscon could just detect a signal on a pin
No, you can't, afaik. USB protocol is way more complicated than a serial transfer. And Syscon has no direct access to USB pins, unlike battery pins.

You can run any programming language on PSP that has a compiler/interpreter for PSP. As with everything else :P

so is there a delphi compiler/interpreter for psp as KylBlz suggested?

Doesn't necessarily need to be a driver. syscon could just detect a signal on a pin
No, you can't, afaik. USB protocol is way more complicated than a serial transfer. And Syscon has no direct access to USB pins, unlike battery pins.

You can run any programming language on PSP that has a compiler/interpreter for PSP. As with everything else :P

Yeah, it's not USB. It'll be through it's special port. No doubt some of the lines are connected to the syscon.

and we cant dump the pre-ipl why?

Because by the time we can load code to read it, it's gone and the ram has been reallocated. The preipl *was* dumped using other, more exotic methods (UPNand voodoo magic).



Err... Kernel exploits are found... in the kernel.

Yes I know but when you are in the vsh you have access to the kernel, so if you find an exploit in the vsh then you have a kernel exploit, right?

The reason VSH exploits are desirable is because they are normally portable media based, this means that users don't have to go out and buy a game in order to execute their exploit, take ChickHEN for example, that utilised a TIFF file exploit and was as simple as placing the image in the appropriate directory along with a binary file in the root of the MS. Also, I think you can take what Mathieulh says as pretty much gospel in these kinds of topics.

Actually VSH exploits are desirable because of ulevel 4, which means you can access the VSH API.

just curious, has anyone tried to exploit the file transfer, i would assume you could send malformed packets and get some type of crash from it.

What do you mean by "file transfer"? You mean USB communication? If so, you can try, but I highly doubt you'll found any flaw in there (exploitable, that is).

filetransfer, as in sending images (files) from one psp to another. (wireless)

That's not a standard option on a PSP. You require homebrew to do so. And why would you like exploiting a homebrew?

If you mean exploitable flaws on the Wifi protocol or TCP/IP stack, well there could be any, although I highly doubt so too.

That's not a standard option on a PSP. You require homebrew to do so. And why would you like exploiting a homebrew?

If you mean exploitable flaws on the Wifi protocol or TCP/IP stack, well there could be any, although I highly doubt so too.

I think hes talking about the send/receive function in the images folder, on OFW.

I think hes talking about the send/receive function in the images folder, on OFW.
yes, i thought that was pretty obvious.
i figure if you somehow send a malformed packet the psp reading it wouldn't know how to handle it and give you a buffer over flow, crash or something

yes, i thought that was pretty obvious.
i figure if you somehow send a malformed packet the psp reading it wouldn't know how to handle it and give you a buffer over flow, crash or something

Did some tests, you can't send a corrupted/unsupported image, and if you receive a corrupted/unsupported image then it won't display it, and if it can't display it you can't exit the image to save it, and if you can't save it then you probably can't do much(so don't try sending chickhen to another psp because it won't work), so I'm not sure if there is much to look at here...

if you're serious about hacking through wireless you should create your own application that sends malformed packets. Sending a malformed image through correct wifi communication will lead nowhere, as you discovered.
And as far as I know, nobody's looked into that very seriously yet.

Usually those protocol stacks (like CSMA/CA) are extensively tested, and most likely used in other Sony devices. It would be hard finding a flaw there. Same goes for TCP/IP.

Actually VSH exploits are desirable because of ulevel 4, which means you can access the VSH API.

I'm not too clear on what that is, but I was speaking from a user's POV, in that a VSH media exploit is a case of "Download the file, allow the PSP to attempt to parse it, exploit executed, done", and also the fact that this way, no cost is incurred buying a game, from a developers POV, Extra "stuff" (ulevel4) is more desirable I guess.

Usually those protocol stacks (like CSMA/CA) are extensively tested, and most likely used in other Sony devices. It would be hard finding a flaw there. Same goes for TCP/IP.

I've often wondered how well the PSP handles malformed WiFi data, but as m0skit0 says, all of the protocols associated with online communications appear to be solid :(

:/ test test, my posts are vanishing.
[edit]
do psp's have running processes (ex, windows has wininet, winlogon, explorer) (that's what .prx's and .elf are right?) if so do we know what they are named (the system ones)?

do psp's have running processes
PSP has no processes, but threads, since it doesn't have a MMU.

that's what .prx's and .elf are right?
You don't have to mix executables (PRXs are ELFs btw) with processes, they're 2 different (but related) things. Executables contain the process image, but also a lot of additional data needed to actually set up the code to be running. So no, ELFs are not processes.

if so do we know what they are named (the system ones)?
Yes.

Did you ever used PSPLINK from Tyranid? If not I suggest you get used to it because it's the basic PSP hacker/developer tool. Of course that requires a CFW'd PSP.

stupid me updated my psp so i cant cfw it :/ (well hbl works) so i can't do to much with it really.

>_> the reason i asked is because i had an idea to get kernel access, i don't know c, but i can do it in pascal. (i also don't know what pspsdk api's are limited to, so it may not be possible)
but it requires knowing a 'process' that the psp needs to run [any kernel level process really].

*i use the word process loosely because i know psp's don't run like windows i just need to compare it to something.

@Cracksman: If you have a PSP 1k or 2k, you could use the DD8 to "downgrade" to a CFW

@pyroesp, is that was the deal i would have done it already :/

I'm interested in your idea.
I did learn Pascal at school and I know how to program in C (I'm not too bad at it :P).

Maybe I could give you a hand ? (if it isn't too difficult ^^")

Ahem, a question regarding a few posts back. When a psp, since they all have it, goes into service mode, what does it read off of? I mean, it has to pick up some execute, does that come from the battery or the flash 0?

Ahem, a question regarding a few posts back. When a psp, since they all have it, goes into service mode, what does it read off of? I mean, it has to pick up some execute, does that come from the battery or the flash 0?

When you insert a battery into a PSP it goes through a pre-power operation which checks the serial number written on the battery EEPROM.
If that serial number is 0x00000000 it will auto turn on and boot from the NAND (Flash0) as normal without you touching the power button, this is known as auto-boot mode. If the battery's serial number is 0xFFFFFFFF then the PSP will power on and boot from the memory stick... This is normal behaviour by the PSP and is by design, the beauty of how/why installing CFW works (Let alone the research that made it possible) is much more complicated.

Edit: m0skit0 you have much more tolerance than I, here's to taking a leaf out of your book...

@cracksman: you can post your idea (if you wish) in Pascal. If you prefer going private, go ahead.

@pyroesp, im self taught.
okay, i actually wrote this for windows not having psp's in mind, but i don't see why you couldn't mod it a little and make it psp-able.
the theory is, if you inject something in to a 'process' (thread) you get all the privileges of that 'process' (thread).

but like i mentioned above, i don't know what the pspsdk api's are limited to so this may not even be possible.
known bugs: if run on windows7 writeprocessmemory throws ERROR_PARTIAL_COPY (getlasterror 299), this is a >Vista memory issue i don't know how to fix it (psp's don't run vista so that okay :D)

uses
windows;

Function Include(Handle: cardinal; EntryPoint: pointer; Size: Cardinal): cardinal;
var
Bnull, OldProtect : cardinal;
Base : pointer;
begin
base := VirtualAllocEx(Handle, nil, Size, MEM_COMMIT or MEM_RESERVE, PAGE_EXECUTE_READWRITE);
VirtualProtectEx(Handle, Base, Size, PAGE_EXECUTE_READWRITE, OldProtect);
if base = nil then exit;
if WriteProcessMemory(Handle, base, entrypoint, Size, Bnull) then
CreateRemoteThread(Handle, nil, 0, entrypoint, nil, 0, Result)
else
messagebox(0, pchar(inttostr(getlasterror)), pchar(':D'), 0);
end;

procedure main;
begin
//this code will be run with all the same privileges as the one you injected it in to.
//so if you get in in a kernel thread you have kernel access.
LoadLibrary('kernel32.dll');//whatever you want
LoadLibrary('user32.dll');//anything
messagebox(0, pchar('hello world 0'), pchar(':D0'), 0);
messagebox(0, pchar('hello world 1'), pchar(':D1'), 0);
end;
procedure mainend; begin end;

var
Pid : cardinal;
HP : cardinal;
size: cardinal;
begin
Size := cardinal(@mainend) - cardinal(@main);

hp := 1234; //get/find the Handle to the Process(Any kernnel thread)
Result := OpenProcess(PROCESS_ALL_ACCESS, False, PID); //open it
include(HP, @Main, Size); //add to it :D
end;


p.s. if you google this code you'll probably find it posted elsewhere cause i was asking about the ERROR_PARTIAL_COPY error :D
p.p.s i think i found a bug in your forum software.

ALSO if all else fails this will cause the 'process' (thread) to crash. which is also good i guess?

I think you should not make comparisions between Windows and PSP. They're absolutely whole different systems. And most important, in Windows you have full privileges over the system, which is not the case on a PSP with OFW. FW has the hand over the user. To resume: you can't inject code into kernel modules without a kernel exploit. So your idea wouldn't work.

I suggest you do some research about PSP internal working, also about how a MIPS CPU operates.

Don't give up though ;)

p.p.s i think i found a bug in your forum software

Could you PM details of this to me please?

in Windows you have full privileges over the system
no, not if your not an admin.
besides the beauty of my snippet is you can run it as a limited user and still get privileges of what you injected it in to. (system processes are not something you can usually mess with, but you CAN use this on it)

you can't inject code into kernel modules without a kernel exploit.
so just elevate your self (SeDebugPrivilege).
Function SetDebug(Hprocess : cardinal): boolean;
Var
NewToken : TOKEN_PRIVILEGES;
PrevToken : TOKEN_PRIVILEGES;
TokenHandle : cardinal;
ReturnLength : cardinal;
begin
Result := false;
if OpenProcessToken(Hprocess, TOKEN_ADJUST_PRIVILEGES + TOKEN_QUERY, TokenHandle) then
begin
lookupPrivilegeValue(nil, pChar('SeSecurityPrivilege'), NewToken.Privileges[0].Luid);
NewToken.PrivilegeCount := 1;
NewToken.Privileges[0].Attributes := SE_PRIVILEGE_ENABLED;
PrevToken := NewToken;
ReturnLength := 0;
if AdjustTokenPrivileges(TokenHandle, False, NewToken, SizeOf(NewToken), PrevToken, ReturnLength) then
Result := true;
end;
end;

^ kernel land
---------(^elevate )----------
user land ^

Yeah, that's what I'm talking about. You cannot elevate your privileges without a kernel exploit. That code is no use at all on PSP.

You cannot elevate your privileges without a kernel exploit
that sounds simple enough but i don't understand. why cant that^ be ran in userland, are X API's just disabled or something?

You cannot elevate the privileges by a simple system call like in your example. I've not programmed Pascal for Windows, but that code seems to simply call an API to elevate the privileges of the process. You first call lookupPrivilegeValue() to check current privilege, then just change it calling AdjustTokenPrivileges().

This is equivalent to having administrator privileges. This is Windows lack of security at work. You cannot do that on Linux for example. Please correct me if I'm wrong.

For PSP:
When running on a MIPS architecture, there are 2 "segments" of memory: user memory and kernel memory. MIPS addresses are 32-bit long, and bit 31 (32nd bit from LSB to MSB) indicates user/kernel. When set to 0, it's user memory, when set to 1 it's kernel memory. So from 0x00000000 to 0x7FFFFFFF it's user memory, and from 0x80000000 to 0xFFFFFFFF it's kernel. Code running on user memory cannot access kernel memory. MIPS CPU internal circuits check that, so you cannot it fool it (except possible unknown CPU exploit). But code running on kernel memory can access any address with no problem.

The only way to switch from user to kernel mode is through exceptions, most notably system calls (SYSCALL instruction), which give access to kernel exported functions. If you find an exploitable vulnerability inside those functions, you can actually "inject" your code into kernel memory and then run it, having thus full priveleges over the console since your code now resides on kernel memory.

I hope this clears it up. If you still think your code can actually run on PSP somehow, I'm all ears.

so are we trying to change bit 31 to 1? (<- is this bit in userland by any chance :D)
The only way to switch from user to kernel mode is through exceptions, most notably system calls
and we can't call system calls in user mode(?).

I think you definitely lack knowledge to understand what I was saying.

so are we trying to change bit 31 to 1?
This makes no sense at all.

is this bit in userland by any chance
This makes no sense, too.

we can't call system calls in user mode
Dude, do you actually read what I write?

The only way to switch from user to kernel mode is through exceptions, most notably system calls

so just elevate your self (SeDebugPrivilege).

Eureka! We've been spending years trying to find exploits, when the only thing we actually had to do was to elevate ourselves. Thanks a lot cracksman!

I'm seriously thinking you're just a troll...

I'm seriously thinking you're just a troll...

lol... I think he's just misinformed, You know how closed minded us windows users can get.

Yeah, he's one of you xDDD

Yeah, he's one of you xDDD

Yea, well... we out number you 10 to 1, I can recall a conversation I had with an AOL tech support guy MANY years ago.

Max: "So, I've installed some patches to get my rockwell winmodem to work, but it doesn't seem to want to communicate with your stuff, I'm running Linux Mandrake 7.1 btw"
Tech: "Ok, which version of windows are you running?"
Max: "I'm not... I'm running Linux"
Tech: "Yes, but which version of windows is that running on"
Max: "Maybe you don't understand, I'm not running any version of windows, I'm running a different operating system called Linux"
Tech: "So... how does your computer work if you don't have windows installed?"
Max: "Nevermind, I'll figure it out myself"

I did eventually figure it out.. It was dialup too.. but since then, I'd rather just have things work in a familiar environment rather than mess around too much... you know what they say, Linux will do absolutely everything you require of it, if time is not an issue for you.

Don't blame the player... blame the game.

On a side note: My mother runs Linux Puppy, does that exonerate me?

Yeah, he's one of you xDDD

Yea, well... we out number you 10 to 1, I can recall a conversation I had with an AOL tech support guy MANY years ago.

Max: "So, I've installed some patches to get my rockwell winmodem to work, but it doesn't seem to want to communicate with your stuff, I'm running Linux Mandrake 7.1 btw"
Tech: "Ok, which version of windows are you running?"
Max: "I'm not... I'm running Linux"
Tech: "Yes, but which version of windows is that running on"
Max: "Maybe you don't understand, I'm not running any version of windows, I'm running a different operating system called Linux"
Tech: "So... how does your computer work if you don't have windows installed?"
Max: "Nevermind, I'll figure it out myself"

I did eventually figure it out.. It was dialup too.. but since then, I'd rather just have things work in a familiar environment rather than mess around too much... you know what they say, Linux will do absolutely everything you require of it, if time is not an issue for you.

Don't blame the player... blame the game.

On a side note: My mother runs Linux Puppy, does that exonerate me?

OMG, I would be ROFL XD

(sorry for off-topic post :D)

(sorry for off-topic post :D)

This post drifted off topic a while ago, there has been some general speculation and some interesting snippets, as well as off topic banter, I don't see too much wrong with it as it is :)

inb4 Mathieulh wades in and slaps this in HOS.

Incidentally, at that point in time in the UK, hardly anyone knew of linux, even some "professionals" seriously.... the reason I wanted to play with it was because I'd been reading some Americans talking about it on a forum, took me 2 weeks just to get the xserver to work properly, never did get the sound working though.

Also, while the Americans where running around with their cable modems we all had 56k v92 modems (if we where lucky), there simply wasn't broadband technology installed anywhere, I can remember being requested by my ISP to call up a special number and "Register my interest" for broadband, I called it about 50 times because the Americans liked to ping me offline for fun or send my rockwell +++ATH0 in an ICMP packet... Nostalgic RAGE!!!

American Guy: "Uh... Max.. can you say buhhhbye?!"
Max: Offline...

Anyway you are right.
</off topic>

For PSP:
When running on a MIPS architecture, there are 2 "segments" of memory: user memory and kernel memory. MIPS addresses are 32-bit long, and bit 31 (32nd bit from LSB to MSB) indicates user/kernel. When set to 0, it's user memory, when set to 1 it's kernel memory.
i was asking 'if we changed that bit to 1 we would be in kernel right'?
then i asked if that bit (bit 31) was user mode accessible (doubtful).

and yes, i did read what you wrote but i thought someone said something about not being able to call system calls (or maybe i got confused and though 'system' has something to do with kernel ???)
lol... I think he's just misinformed, You know how closed minded us windows users can get.

we have a winner!

At the risk of this thread ending up in the HOS I'll bring things back on topic.

@cracksman, there are many things wrong with your example.

Firstly, the privileges you are talking about are purely OS-level security. It is something that Windows itself implemented to separate privileges between users.

The correct Windows/x86 analogy to what m0skit0 is trying to explain (the separation of user/kernel mode via system calls) would be something like this:

As an example, the ReadFile function (a very common WinAPI call):

User_mode[app calls ReadFile -> calls the NativeAPI equivalent NtReadFile in kernel32.dll -> calls the processor-dependant trap instruction in ntdll.dll] -> system call software interrupt -> Kernel_mode[calls the real NtReadFile code in ntoskrnl.exe]

This is how user code reaches kernel code, it is dependant on the architecture: on x86 they use the 'int 0x2E' instruction, more modern Intel x86 cpu's use the 'sysenter' instruction, AMD x86 cpu's use the 'syscall' instruction (they all do the same thing).

What you have described is the Windows-specific mechanisms of handling access tokens, something which is needed for a multi-user OS. The PSP is NOT a multi-user multitasking OS. Anything using Se* of the WinAPI is part of this Windows security system (the security reference monitor). It has nothing to do with how the PSP OS works.

On a side note, those WinAPI calls you mentioned work just as well in C (or .net for that matter).

thanks for clearing that up(although im still a bit confused, probably because im not used to it).
so as an example, on a psp, if you call ReadFile in usermode you can only read things in usermode [eg. kernel is off limits] right?
-
so is there ever a time where any user land api is used in kernel land?
boot time/game launching/game saving/ect

and how did [whatever] game exploit get kernel access?

i was asking 'if we changed that bit to 1 we would be in kernel right'?
then i asked if that bit (bit 31) was user mode accessible (doubtful).
Programming 101 (BOTH PSP AND PC): your code, when running, is on main memory (RAM), I guess you already knew this. As such, he's at some address when running, for example address X. CPU just fetches the instruction from that address X, executes it, then fetches instruction from address X+1, executes it, and so on.

What I meant by user/kernel mode on PSP was that if the address of the executing code as bit 31 = 0, then you're on user mode. If it's set to 1, then it's kernel mode. If you change bit 31, you'll end up with a whole different address, and your code will not be there anymore. And anyway, you can't call a kernel space code directly from a user space code, it will raise an invalid address exception. I hope this clears things up.

Anyway, I suggest you again to check some tutorial about how code actually runs on a machine, at low-level (assembly) so you can understand it better. If you didn't know, everything is translated to machine language to run (even Pascal), as processors only understand that.

so is there ever a time where any user land api is used in kernel land?
You didn't get what SilverSpring told you. All API code is on kernel land (well I'm bending the truth, but anyways). So for your code that runs on user mode to be able to call those APIs, he has to switch to kernel mode, which can only be acheived by SYSCALL instruction (which triggers an exception, which is the equivalent of a software interruption for IA32). This SYSCALL has a number, which is handled by the kernel to see what service you've requested, then pass it to the proper kernel function, then use RTE (IRET on IA32) to return from an exception, and back to your user mode code.

and how did [whatever] game exploit get kernel access?
By finding a vulnerability on a kernel function and exploiting it. If a kernel function accessable through standard PSP API is vulnerable, you can trick it to copy your code into kernel space, then call it using another (or the same) API call. Then you'd be running on kernel space with full privileges.

Again, I suggest you get to know how programming actually works, because high-level prorgamming for Windows won't yield anything useful on PSP.

derp, okay its me again with another idea.

couldn't you replace a prx with a modded one with your code? (i don't know much about the innards of psp's as you can see^ but hang with me)
so for example lets pretend there is a note_botton.prx normally when you push the 'note' button this .prx is called and messes with the volume controls. now if you replaced this note_button.prx with your own or patched it to JMP to some code elsewhere, when you push the 'note' button wouldn't your code run? (if it was a kernel .prx would your code be run in kernel land?)

derp, okay its me again with another idea.

couldn't you replace a prx with a modded one with your code? (i don't know much about the innards of psp's as you can see^ but hang with me)
so for example lets pretend there is a note_botton.prx normally when you push the 'note' button this .prx is called and messes with the volume controls. now if you replaced this note_button.prx with your own or patched it to JMP to some code elsewhere, when you push the 'note' button wouldn't your code run? (if it was a kernel .prx would your code be run in kernel land?)A kinda similiar exploit was used back in 1.50 firmware, where you were able to swap a prx (from exceptionman till init.prx) with a plain one which must not have any kernel mode attributes or imports. But Sony (of course) fixed that exploit later (1.52?). So in order to get this working in new firmware you'd have to encrypt your prx and flash it. Dead end.

derp, okay its me again with another idea.

couldn't you replace a prx with a modded one with your code? (i don't know much about the innards of psp's as you can see^ but hang with me)
so for example lets pretend there is a note_botton.prx normally when you push the 'note' button this .prx is called and messes with the volume controls. now if you replaced this note_button.prx with your own or patched it to JMP to some code elsewhere, when you push the 'note' button wouldn't your code run? (if it was a kernel .prx would your code be run in kernel land?)

To read and write in the flash mem of the PSP you'll need a kernel exploit.
A program in user mode can only read those mem.

A kernel exploit allows you to read and write, but I don't see the point in doing that if you have a kernel exploit.

Even if you have a kernel exploit you cannot do that. As explained by Dr. Soup, PRX are encrypted, and any modification will make them corrupt. The only way you have to modify an encrypted file is decrypting, modifying, and then encrypting again. But you cannot do that because PSP's encryption algorithm is unknown (although some guesses have been done, but nothing 100% sure), same as the keys used.

Anyway, such ideas are very basic and you should expect other people have thought about this before you, since PSP has now 5+ years on the market ;)

any modification will make them corrupt.

Silverspring states that he can modify headers... lol this is over my head but that's worth mentioning...

Even if you have a kernel exploit you cannot do that. As explained by Dr. Soup, PRX are encrypted, and any modification will make them corrupt. The only way you have to modify an encrypted file is decrypting, modifying, and then encrypting again...

I should have mentioned that :D

any modification will make them corrupt.

Silverspring states that he can modify headers... lol this is over my head but that's worth mentioning...

If memory serves me well, the only thing that protects them is a SHA-1 checksum and some scrambling. They only hold information about the size and information about the extra non-KIRK encryption that PRX's have (eg. XOR with a kernel key). You can change them all you want, it is still going to feed the body of the file to KIRK and won't pass the checks.

i read that anything run from the UPDATE folder runs as kernel is that true?
from pspiso:...nothing ever runs in kernel mode apart from the update folder in the ms0:/eh:0 and UMD

i read that anything run from the UPDATE folder runs as kernel is that true?
from pspiso:...nothing ever runs in kernel mode apart from the update folder in the ms0:/eh:0 and UMD

Yeah, that is true, because the PSP KERNEL doesn't even run in kernel mode ofc.

i read that anything run from the UPDATE folder runs as kernel is that true?
from pspiso:...nothing ever runs in kernel mode apart from the update folder in the ms0:/eh:0 and UMD

Yeah, that is true, because the PSP KERNEL doesn't even run in kernel mode ofc.

Really? if thats the case then hopefully there can be way to hex edit the checksum of the eboot using sonys code with our crack code to make kernal exploits work.

to hex edit the checksum of the eboot using sonys code with our crack code to make kernal exploits work.

If you have a kernel exploit, you don't need to encrypt anything. And vice-versa :).

i read that anything run from the UPDATE folder runs as kernel is that true?
from pspiso:

Yeah, that is true, because the PSP KERNEL doesn't even run in kernel mode ofc.

Really? if thats the case then hopefully there can be way to hex edit the checksum of the eboot using sonys code with our crack code to make kernal exploits work.

1) HE WAS BEING SARCASTIC.
2) The updater doesn't run in kernel mode.

The updater runs in "updater" mode....

i didn't think it was true but i thought id ask anyways.

...
2) The updater doesn't run in kernel mode.

okay it doesn't run in kernel mode but its got to access kernel mode somehow to update right?(i mean, it sounds logical, kernel &updating go hand in hand right?)
@Mathieulh what is this updater mode you speak of?

i didn't think it was true but i thought id ask anyways.

...
2) The updater doesn't run in kernel mode.

okay it doesn't run in kernel mode but its got to access kernel mode somehow to update right?(i mean, it sounds logical, kernel &updating go hand in hand right?)
@Mathieulh what is this updater mode you speak of?

It's got updater mode, which has certain modules loaded compared to other modes (which can give certain advantages). The updater loads some module which have kernel attributes yes, but the updater runs in updater mode.

It's got updater mode, which has certain modules loaded compared to other modes (which can give certain advantages). The updater loads some module which have kernel attributes yes, but the updater runs in updater mode.
Does that mean that updater mode is actually user mode with some extra privileges?

It's got updater mode, which has certain modules loaded compared to other modes (which can give certain advantages). The updater loads some module which have kernel attributes yes, but the updater runs in updater mode.
Does that mean that updater mode is actually user mode with some extra privileges?

Exactly. Plus, there's a module loaded (vshbridge) in updater mode that allows you to load kernel modules from a different location than just flash0, such as from the updater itself (they still have to be signed and encrypted, though). Inside user mode the only place you can load kernel modules from is flash0.

I knew it (a little) lol, so Bubbletune your saying that loadin the vshbridge.prx can be used on an exploit? because i was thinking of coding/creating a little 6.20 kernel mode myself but not really sure if im doing it correctly, i was thinking of using the hello world source codes from C. by using the same excat but from the ex. decrypt vsh/modcule/any.prx and see if the image or tiff from my Wip exploit from PICTURE or VIDEO (i guess) please feel free to correct me im just kinda startin a bit atm.

I knew it (a little) lol, so Bubbletune your saying that loadin the vshbridge.prx can be used on an exploit? because i was thinking of coding/creating a little 6.20 kernel mode myself but not really sure if im doing it correctly, i was thinking of using the hello world source codes from C. by using the same excat but from the ex. decrypt vsh/modcule/any.prx and see if the image or tiff from my Wip exploit from PICTURE or VIDEO (i guess) please feel free to correct me im just kinda startin a bit atm.

... You obviously have absolutely no idea what you are talking about. The sentence isn't even coherent.

You should 1. Know what you are talking about before you stay stuff (and that means research, people) and 2. Actually form a sentence that makes sense.

If this thread has any more un-researched stupid theories then I will be closing it.

sorry, i know it didn't made any sense that time but i wanted to know what i was doing before i go on researching things and not watse my time at the wrong thing. CloudHunter and 2) i know when i need to research it or not at the time i just to know if its correct FIRST so it won't be a complete waste of my time like said before. and again sorry and i promise it won't turn out to this again.

I knew it (a little) lol, so Bubbletune your saying that loadin the vshbridge.prx can be used on an exploit?

No... all it does is provide an API to load SIGNED, ENCRYPTED kernel modules from the memory stick. Also, you can't load it outside of VSH/updater mode.

I knew it (a little) lol, so Bubbletune your saying that loadin the vshbridge.prx can be used on an exploit?

No... all it does is provide an API to load SIGNED, ENCRYPTED kernel modules from the memory stick. Also, you can't load it outside of VSH/updater mode.

oh okay so its just a loader to load your signed encryption that you've made to go into kernel mode. and btw is usermode easier than kernel mode?

Do you have any idea what you are talking about?

Updater Mode is just User Mode with elevated priveledges ie. load Sony Signed modules off the memory stick and flash0 write access.

I don't understand what you mean by 'is user mode easier than kernel mode'. AFAIK the PSP never runs in kernel mode, it just interfaces with the kernel through syscalls.

EDIT if you mean 'is it easier' to find exploits then yes.

Metroid_III & DSwizzy145, please stop talking nonsense. If you don't know, ask. Don't make nonsense sentences like "PSP never runs in kernel mode" or "is user mode easier than kernel mode"... o.O

I knew it (a little) lol, so Bubbletune your saying that loadin the vshbridge.prx can be used on an exploit?

No... all it does is provide an API to load SIGNED, ENCRYPTED kernel modules from the memory stick. Also, you can't load it outside of VSH/updater mode.

oh okay so its just a loader to load your signed encryption that you've made to go into kernel mode. and btw is usermode easier than kernel mode?

This is ridiculous.

Forget everything you've "learned", and learn it all properly from the beginning. If you can't even understand when someone tells you something correct, you need to learn from the beginning and how to read.

If I see one more stupid question/answer from you in this thread you're looking at a ban. I'd like to keep this topic open as it keeps some stupid questions out of the main forum.

Metroid_III & DSwizzy145, please stop talking nonsense. If you don't know, ask. Don't make nonsense sentences like "PSP never runs in kernel mode" or "is user mode easier than kernel mode"... o.O

Sorry m0skit0. I actually made that assumption because the kernel is supposed to always run in the background with threads connecting it to user mode, right? The user interfaces with user mode, and is limited by what the kernel will let them do. It shouldn't ever be truly in kernel mode because that would suggest that the user has full control over the system. Feel free to inform me of why I'm wrong.

The initial loaders (Pre-IPL and IPL) run on kernel mode obviously. Then the actual kernel is loaded by them, again on kernel space. The kernel initializes itself, then loads the VSH on user mode. From now on, everything loaded by the user will be loaded on user memory, with the exception of eventual kernel modules needed by the game/VSH. User mode modules require advanced services which involve access to the console hardware, but direct hardware interfacing can only be done on kernel mode, so user mode modules require services from the kernel (such as reading a file from MS) through system calls. So I would say that most code run by the PSP is actually kernel code.

Anyway, this is basic PSP architecture (I could even say general operating system knowledge) for you to have if you're expecting to post on such a development forum.

Relax man, just kidding and besides i do know half of this stuff FYI but i just wanted a simple and calm Question and yes kernel does run from the consoles Ram and flash0 access. and user mode does require binary code to run things easier so Relax Moskit0 i do know what i mean but i know i dont explain things 100% clear at most times but at least half of it does makes since not all!

Chill OUT Cloudhunter, sorry about your little thread and also FYI i actually do know what the heck im talkin about and i do know about hex editing and address values by encryptin the code or decryptin the code and things about the psplink by finding crashes that can help get into two diffrent modes so relax and i promise this will never happen again.

The initial loaders (Pre-IPL and IPL) run on kernel mode obviously. Then the actual kernel is loaded by them, again on kernel space. The kernel initializes itself, then loads the VSH on user mode. From now on, everything loaded by the user will be loaded on user memory, with the exception of eventual kernel modules needed by the game/VSH. User mode modules require advanced services which involve access to the console hardware, but direct hardware interfacing can only be done on kernel mode, so user mode modules require services from the kernel (such as reading a file from MS) through system calls. So I would say that most code run by the PSP is actually kernel code.

Anyway, this is basic PSP architecture (I could even say general operating system knowledge) for you to have if you're expecting to post on such a development forum.

Thanks for the excellent explanation m0skit0, I guess I wasn't thinking too much when I made that comment. I'll make sure to be careful of my info from now on :)

@DSwizzy145: if you don't know how to explain something (and you obviously don't), then you actually don't know that thing. Plain simple.

@m0skit0 FYI i do but i was being sarcastic on my info i actually do know things about the pre ipl, user mode & kernel modules and also im sorry for the nonsense i've made on that comment like said this problem will not occure again ever.

All I see is too much talking and no proofs.

Kirk is hardware. Kernel exploits are exploits found in the vsh, they will most likely be found in formats such as mp3, tiff, png, mp4 ect. Pandora battery's were originally created by Sony, they used it as a shortcut to reflash and bricked psp, I'm not sure how hackers cracked it, but its in a vid somewhere on this forum, and no service mode didnt' disapear on the 3k or the GO, sony just change the ipl and pre-ipl so our magic memory sticks won't work...

The pandora battery was discovered by a system modder by the well known name of "ben heck" Now I also know that there where others that found the pandora battery. (like soft modding) but ben found the Hard mod witch was found long before the soft modding.

As for your question finding cracks and explotes in the PSP is done thoue PSPLink. (Most of the time)

Kirk is hardware. Kernel exploits are exploits found in the vsh, they will most likely be found in formats such as mp3, tiff, png, mp4 ect. Pandora battery's were originally created by Sony, they used it as a shortcut to reflash and bricked psp, I'm not sure how hackers cracked it, but its in a vid somewhere on this forum, and no service mode didnt' disapear on the 3k or the GO, sony just change the ipl and pre-ipl so our magic memory sticks won't work...

The pandora battery was discovered by a system modder by the well known name of "ben heck" Now I also know that there where others that found the pandora battery. (like soft modding) but ben found the Hard mod witch was found long before the soft modding.

As for your question finding cracks and explotes in the PSP is done thoue PSPLink. (Most of the time)

Pandora's Battery was originally used by Sony, it was reversed engineered by hackers. And crashes are examined through PSPLink, but they must be found first in one of the aforementioned vectors aka mp4, mp3, gif, tiff, etc.

Metroid The pandora battery never was reverse engineered because we never had one, what we did was a lot of trial and errors with the serial pin of the battery in the hope of triggering the service mode (which was really getting syscon to set a gpio register)

The battery part was figured once the IPL block was forged, in fact the battery was the easy part, it took less than a week to be done (though we initially had the serial gnd pin cut so the battery would send all FF then later on the functions to reprogram the eeprom were figured out), vs about 6 months to figure how to dump the pre-ipl through an exploit, time attack kirk, forge the block etc etc

I read somewere that battery/card was reversed because sony guy forget it in console after repairing... Just a joke or mistake?

I always thought the battery serial thing was a bit sloppy, why all FF's/00's? why not some random arbitrary value.

I read somewere that battery/card was reversed because sony guy forget it in console after repairing... Just a joke or mistake?

That was a clue that it had something to do with the battery. It was up to them to confirm it and figure out what it was. It was never reverse engineered. I'm quite sure they never even possessed that battery.

I read somewere that battery/card was reversed because sony guy forget it in console after repairing... Just a joke or mistake?

Occasionally service memory sticks from Sony service centres turn up, but distributing their contents is illegal, even so that hasn't stopped them ending up in a few peoples collections.

why all FF's/00's? why not some random arbitrary value
Maybe because at first time they used hardmodded batteries, and the resulting value read was FF's. Putting a random value would require a slighlty more complicated hardware. Also might be so they could have a special value not on the middle of serial numbers domain, which would be confusing for third-party manufacturers. Not really worth the effort, as I think Sony was not relying on this serial number as a security feature, but rather on Pre-IPL checks for a valid IPL.

Metroid The pandora battery never was reverse engineered because we never had one, what we did was a lot of trial and errors with the serial pin of the battery in the hope of triggering the service mode (which was really getting syscon to set a gpio register)

The battery part was figured once the IPL block was forged, in fact the battery was the easy part, it took less than a week to be done (though we initially had the serial gnd pin cut so the battery would send all FF then later on the functions to reprogram the eeprom were figured out), vs about 6 months to figure how to dump the pre-ipl through an exploit, time attack kirk, forge the block etc etc

Thanks for the explanation. While I did realize you guys never had an actual Pandora, reverse-engineered was the 1st word that came to mind because most sites just throw that word around meaninglessly. Anyway, thanks. Very insightful.

Maybe because at first time they used hardmodded batteries, and the resulting value read was FF's. Putting a random value would require a slighlty more complicated hardware. Also might be so they could have a special value not on the middle of serial numbers domain, which would be confusing for third-party manufacturers. Not really worth the effort, as I think Sony was not relying on this serial number as a security feature, but rather on Pre-IPL checks for a valid IPL.

I didn't think about it like that... makes sense now, besides... the battery was only security through obscurity, it wasn't a real attempt at a security concept, they left that to the (pre)IPL.

but distributing their contents is illegal
Their contents are: some .prx.enc (encrypted) files, .bin OS/flasher (encrypted?), parental_lock.bin (not encrypted and not checked but used by OS in installation) and an ofw =)

but distributing their contents is illegal
Their contents are: some .prx.enc (encrypted) files, .bin OS/flasher (encrypted?), parental_lock.bin (not encrypted and not checked but used by OS in installation) and an ofw =)

Ultimately useless too... can you decrypt and then re-encrypt the .enc files on a new MS or hack an MSID?

I can't...

No, i can't encrypt files back. And i have some decrypted files that decrypted by someone (i'm really don't know who did it).
There is other way to copy jigkick ms. And it's totally secret. And need some special hardware =)

No, i can't encrypt files back. And i have some decrypted files that decrypted by someone (i'm really don't know who did it).
There is other way to copy jigkick ms. And it's totally secret. And need some special hardware =)

lol.... you're just spoofing or re-writing the MSID, that's not secret :p

Arduino proxy spoofer?

Secret is how to do it. It's not simple =)

Secret is how to do it. It's not simple =)

Nothing ever is... I'm reasonably confident that with an Audrino and some other stuff I could spoof an MSID.

But from what I hear.. you're ordering "specific" memory sticks... I'll leave it at that lol.

He-he, i'd like to know how to start psp-3000 in service mode =) Without any hardware mods.

He-he, i'd like to know how to start psp-3000 in service mode =) Without any hardware mods.

Wouldn't we all :)

He-he, i'd like to know how to start psp-3000 in service mode =) Without any hardware mods.

Wouldn't we all :)

that would be awesome to do so :) i'll be just like bootmii but on PSP lol :D

He-he, i'd like to know how to start psp-3000 in service mode =) Without any hardware mods.

Wouldn't we all :)

that would be awesome to do so :) i'll be just like bootmii but on PSP lol :D

No, it wouldn't... we don't have control.. just service mode, booting to the memory stick isn't even half the battle, you might as well replace your memory stick with cheese for all the good it'd do.

Booting from MS = Half Unbrick/Downgrade.

Booting from MS = Half Unbrick/Downgrade.

Incorrect.... booting from MS is the easy part.. the pre-ipl/ipl timing attack + brute force, then actually understanding wtf is going on is most of the battle... the service mode battery was nothing in comparison.

Also, starting with PSP-300X, the ipl can no longer be directly decrypted by Kirk. You will see 1 at position 0x62 and I think that is a flag to indicate some "decryption" required on the first 0x40/0x60 bytes

MaxMouseDLL,
1st part = service mode
2nd part = sony card
1+2=megaultrahack =)

MaxMouseDLL,
1st part = service mode
2nd part = sony card
1+2=megaultrahack =)

No, the first part is dumping the pre-ipl, the second hardest task of all.

Bubbletune,
any ideas about pre-ipl dumping? Kexploit? Decap?
P.S. How Brokencodes did it?

Kernel exploits cannot dump Pre-IPL since it's no longer mapped to any memory address. Although if IPL actually de-maps Pre-IPL, cannot we just remap it through Syscon or something like that?

I think Brokencodes simply brute-forced a part, although I'm not even sure Brokencodes's results were real or fake. Anyway, the only way to know is actually asking him xD

Bubbletune,
any ideas about pre-ipl dumping? Kexploit? Decap?
P.S. How Brokencodes did it?

Back in old PSP's it was possible to remove blocks from the IPL because there were blocks that had a zero checksum, and they just so happened to use the value of zero to specify there being no block in front of it. Thus, you could leave a leap of unused memory right at the entry point (as long as the new block at the start had a zero checksum), and if booted to another firmware with a modification chip, stuffed code there and power cycled, it would execute it before the CPU resets to get rid of the pre-IPL. This was fixed in the newer models, however.

Also, there is no reason at all to assume that Brokencodes had dumped the pre-IPL.

Also, there is no reason at all to assume that Brokencodes had dumped the pre-IPL.

If I remember correctly, Dark_Alex was working on understanding the extra checksum that was in the IPL; this was a mystery and the pre-IPL was needed to understand how the checksum worked. Since the website is down, I can't link to Dark_Alex's post but this is a quote I found:

"Summary: basically, all security of newest PSP cpu's rely on the secrecy of the calculation of those 0x20 bytes. If pre-ipl were dumped somehow, the security would go down TOTALLY. "

Edit: it can be found here:
http://www.psp-hacks.com/2008/10/06/why-psp-motherboard-ta88v3-cannot-be-hacked-yet/

Again IIRC, Brokencodes purported to know how this checksum worked (source was posted as well, I have this somewhere but not on this computer), and in further analysis Dark_Alex said it was code "to forge a portion of the IPL signature block" but not the entire thing (as per Sceners.org but that is also down ATM so no link).

Even when the IPL is figured out, on TA-088v3 and higher we still need a method to put the PSP in service mode, which the infamous 'blue lite tool' was purported to do (whether through a "crypto processor" or doing some funny stuff with the voltage level is still unknown).

TA-088v3 works with standart pandora battery (bandora pattery, he-he).
Now i have two psp-2001 ta-088v3 5.03, but how to dump? =)

May anyone reupload despertar 7 source code?

Also, there is no reason at all to assume that Brokencodes had dumped the pre-IPL.

If I remember correctly, Dark_Alex was working on understanding the extra checksum that was in the IPL; this was a mystery and the pre-IPL was needed to understand how the checksum worked.
He posted information he found after taking a look at the new IPL format, I have my doubts that he was actually working on cracking it.

Again IIRC, Brokencodes purported to know how this checksum worked (source was posted as well, I have this somewhere but not on this computer), and in further analysis Dark_Alex said it was code "to forge a portion of the IPL signature block" but not the entire thing (as per Sceners.org but that is also down ATM so no link).

I never really took a close look, but it could've been so that SCE was just using a standard hashing algromithm and Brokencodes found it by trial-and-error, or something similiar to that. If he had dumped the pre-ipl he would've had more information, not just a part.

Even when the IPL is figured out, on TA-088v3 and higher we still need a method to put the PSP in service mode, which the infamous 'blue lite tool' was purported to do (whether through a "crypto processor" or doing some funny stuff with the voltage level is still unknown).

You can still use custom IPL blocks to write custom firmwares, even if you don't have service mode. :p Also, there's probably a clue to how service mode is enabled on these new models in the pre-IPL.

A little side-note before people forget: Custom IPL blocks use an exploit in the pre-IPL. There is no reason to assume that the new checksum is the only change. It's good security as it stops you from downgrading to older firmwares alltogether and it invalidates current custom IPL blocks, but the chances that they actually fixed the exploit are large, in which case calcuating the hash using code reversed from a pre-IPL dump won't get us any closer.

(i assume there is a reason we can't or it probably would have been done already)
we can dump memory correct? so couldn't someone dump mem when kirk is run, then step through the ASM to see how it works? (reverse it kindof like how you would make a keygen, then implant that in our homebrew)

If you want to dump memory with ipl info, you must write custom ipl with memdump code. If you want to flash custom ipl to ta-088v3 nand, you must sign it.

(i assume there is a reason we can't or it probably would have been done already)
we can dump memory correct? so couldn't someone dump mem when kirk is run, then step through the ASM to see how it works? (reverse it kindof like how you would make a keygen, then implant that in our homebrew)

KIRK isn't in the RAM memory. It's a seperate chip on the CPU.

Snipped - Ninja'd!

Yeah... we can just wait sit and wait for a Pre-IPL exploit to pop up on our desktops and then create forged IPL blocks.

Fun.

-arnater

Forged IPL blocks... Hmmm, tasty.

i've found a good website that makes complete understand (for the Noobz) here on how buffer overflow works propertly, here's the link ;) http://users.abo.fi/fbjon/segfault/ Enjoy :)

i've found a good website that makes complete understand (for the Noobz) here on how buffer overflow works propertly, here's the link ;) http://users.abo.fi/fbjon/segfault/ Enjoy :)

Dammit I'm getting tired of this crap from you. What the hell is that you just linked to?

Have a one-week ban and take some time off (hopefully it'll do you good). I've put off banning you for a long time, one more stupid-ass post from you and you get a permanent IP ban.

The guy who wrote that web page has absolutely no idea about what he's talking. "Buffer overflows are programs"? WTF? xD Most likely written by DSwizzy145 himself, IMO.

WTF did I just read?! ... I'm going to go lay down for a while, a week ban was lenient...

The guy who wrote that web page has absolutely no idea about what he's talking. "Buffer overflows are programs"? WTF? xD Most likely written by DSwizzy145 himself, IMO.

From the site itself.

This is, of course, a parody/modification on the original Ninja power site. Nothing can beat it in weirdness.

And the site the parody is based on: http://www.realultimatepower.net/

I really hope he was joking and didn't think the site was real.

Sorry Cloudhunter, didn't notice

Sorry Cloudhunter, didn't notice

Don't be sorry - or do, but only sorry that the site exists :p

Anyway, now that... Interesting... Interuption is over, let's get back to the topic. Use it wisely, he'll be back in one week saying stupid stuff again.

I really hope he was joking and didn't think the site was real.

Joke or not the ban still stands either way. Crap like that doesn't belong here and he has posted plenty of crap (possibly even 100% crap-posts so far from him in his short time here).

If one was trying to brute force Sony's signature can others use their computers to connect to the guy's computer via internet and help him with providing cpu?
Like that thing on ps3 where you go on something in the xmb under the network tab and it contributed to some kind of research. (This was a while back and I can't remember what it was called.)

You mean a collaborative network of PS3's with the aim of cracking Kirk?

Setting it up seems to be more complicated than actually cracking Kirk. :P

-arnold

The cracking has to happen actually on the PSP... you could in theory setup some elaborate distributed crack attempt, but coding it is actually pretty hard (I did something similar a while back to brute force SHA-1 NIDS to their function names, I managed to find maybe two legit ones, the app was called NIDCRK).

I wouldn't like to attempt to code homebrew to do that...

Besides, cracking a particular input isn't what we're after, what we want to know is the algorithms associated with the encryption and signing process, brute force isn't an option.

You mean a collaborative network of PS3's with the aim of cracking Kirk?

Setting it up seems to be more complicated than actually cracking Kirk. :P

-arnold

I was just using the ps3 as an example.
@MaxMouseDLL You're saying it can be done, but it would be kinda useless?

I was just using the ps3 as an example.
@MaxMouseDLL You're saying it can be done, but it would be kinda useless?

I don't even think you can brute force it... we don't even know the algorithm (encryption/signing) to attempt it.

We need to know the steps from an unencrypted piece of data to it's encrypted and signed version... we simply don't know them... brute force is useless in this instance, even if it where useful the fact that it's encrypted AND signed would increase the possibilities exponentially, meaning that you'd probably need more people running this thing than the population of earth (Depending on the size of data you're trying to brute force).

You'd need an infinite amount of monkeys, sitting at an infinite amount of computers, typing for an infinite amount of time... you'd get your encryption and signing algorithm... you'd also get the complete works of Shakespeare and everything else ever written, being written or ever will be written... but that's besides the point...

They brute forced some blocks of the IPL, that's how pandora works...

Edit: What we need to do is write some code that allows access to the flashes and the capability of running unsigned code, then somehow have Sony sign it, this kind of thing happened recently with the iPhone, a guy made a crappy flash light app, but hid inside it some code to allow tethering... apple made it available on the appstore and boom, everyone that downloaded it had restriction-less tethering. Apple discovered their screw up and tore the app down... but it's a cool demonstration of covert capabilities.

I was just using the ps3 as an example.
@MaxMouseDLL You're saying it can be done, but it would be kinda useless?

I don't even think you can brute force it... we don't even know the algorithm (encryption/signing) to attempt it.

They brute forced some blocks of the IPL, that's how pandora works...

Hmm I wonder what Datel did.

Datel melted the IC casing with acid, put the KIRK (and probably Spock and all other de-capped IC's) into a scanning electron microscope or similar, then had guys pouring over the images of hard coded logic gates/components etc, with that information they where able to reconstruct the signing and encryption algorithms by simply looking at the hardware in detail... this kind of thing is very expensive and if there where a shortcut way to doing this kind of thing you can be sure datel would have done that instead.

There are companies (Like Chipworks) which will decap IC's for you and provide you with a detailed report for reverse engineering, there are legitimate reasons for this kind of service (A company that has developed an IC for you, but has then gone bust, or you inherit some hardware and have no idea how it works...) - (I've tried, they (Chipworks) won't speak to me), even so... even if we had this kind of information... we'd be hard pressed to understand it, and I'm told it probably wouldn't be enough anyway.

Oh jeez..that sound exspensive.
Next thing you know people start a donation found for that.lol
Well anyway, why wouldn't it be enough?

We don't even know if it is hardcoded logic or a ROM.

We don't even know if it is hardcoded logic or a ROM.

Unfortunately..

Oh jeez..that sound exspensive.
Next thing you know people start a donation found for that.lol
Well anyway, why wouldn't it be enough?

I already tried this, I was going to approach Mathieu to see if I could steal a spare PSP (or two) from him to send to Chipworks, but after an initial conversation with Chipworks they decided to ignore me, so I couldn't even start trying to raise funds, why don't you give it a shot, see if you have more luck.

Edit: it's like this (1 + 2) = 3 where (1 + 2) is decrypted data, 3 is encrypted and signed data, explain that to me assuming you have no concept of numbers (Encryption) or math (Signing)... all you're left with is the fact that a given input gives a certain output... you cannot describe how it works, just that it works... it's what's known as a "Black box"

Any reason they started ignoring you, Max?

Any reason they started ignoring you, Max?

Have a think about it... say for example that I managed to raise the funds, Mathieul gave me 3 PSP's for the project, I send them all to chipworks, they send me back a complete rundown of every IC in the thing, we find someone who knows how to interpret the data, he gives us back the encryption and signing algorithms... overnight we can legitimately sign and encrypt our own homebrew, and because of backward compatibility Sony can do nothing about it, their security has gone down TOTALLY, there is now nothing they can do to stop us.

A few hours later, Sony find out who's responsible for giving us this information.. Chipworks.... you think they want to be involved in that war? hell no... they want Joe soap, who's just took over a business.. has some hardware and isn't on great terms with it's developers, he owns the rights to the hardware so they reverse engineer it for him, everyone is happy... everyone gets paid..

They DO NOT want a legal battle....

Never thought about it like that..



Imagine that power..the fact that sony wouldn't be able to stop us...sounds like a homebrew dev's dream...sounds like sony's nightmare.

Never thought about it like that..

Imagine that power..the fact that sony wouldn't be able to stop us...sounds like a homebrew dev's dream...sounds like sony's nightmare.

When the PSP is "dead" something like this may surface... or maybe when Sony deems the PSP to be dead they will leak it...

Say for example Sony leave the PSP which they eventually will... running homebrew/(lets face it) pirate games on it, may garner them some revenue... The PSP's death throws may be just that... but not for a long time yet.

The homebrew scene will die... the PSP will die.... once it's all said and done, it might be in Sony's interest to tell all... I hope so...

That would most likely reveal some of their internal secrets, still being used in other hardware, I don't see them leaking it. However, once no firmware update is done anymore for the PSP, then a kernel exploit will be good enough.

Wololo, not to be too nosy in your buisness, but has anybody, anybody at all come forward to you with a kernel exploit? This is killing me..

People who have the ability to find Kernel exploits know much more than I do, why would they come to me for help?
If anything, I would be the one coming to these guys to see if they could make some use of some user mode exploits.

People who have the ability to find Kernel exploits know much more than I do, why would they come to me for help?
If anything, I would be the one coming to these guys to see if they could make some use of some user mode exploits.

Lol I see.

I know that ofw 6.xx has patched many of known kexploits. Why still no 5.05-5.50-5.51-5.55-5.70 to 5.03 downgrader with this "useless" kexploits?

i've found a good website that makes complete understand (for the Noobz) here on how buffer overflow works propertly, here's the link ;) http://users.abo.fi/fbjon/segfault/ Enjoy :)

ROFL that made my day xD

I know that ofw 6.xx has patched many of known kexploits. Why still no 5.05-5.50-5.51-5.55-5.70 to 5.03 downgrader with this "useless" kexploits?

Maybe developers don't wanna? It takes time. Also, 5.70 -> 5.03 isn't possible.

Also, 5.70 -> 5.03 isn't possible.

Excuse my ignorance, but why wouldn't it be possible to downgrade to firmware 5.03 from 5.70? Is it the changed NIDs or something? or perhaps something else? Shed some light pleaz and thnkx

Also, 5.70 -> 5.03 isn't possible.

Excuse my ignorance, but why wouldn't it be possible to downgrade to firmware 5.03 from 5.70? Is it the changed NIDs or something? or perhaps something else? Shed some light pleaz and thnkx

PSP 3000's that came with 5.70 are actually PSP 4000's. All it'd help would be slim users and early 3000 users.

A HEN would be possible, but after what happened last time I doubt people would bother.

PSP 3000's that came with 5.70 are actually PSP 4000's. All it'd help would be slim users and early 3000 users.

A HEN would be possible, but after what happened last time I doubt people would bother.

Firstly, that is for PSP 3000's that have been originally set with firmware 5.70. What about all the other PSP's originally set to 4.01(first firmware?) and others? However, I guess in the end, I would just create more pirates then people creating homebrew =/

Second, if these kernel exploits are patched on newer firmwares, whats the harm in their release? It would just bump people up to a new firmware, or even bring the CFW to the PSP Go? There are still many possibilities with these exploits, and I'm pretty sure that the current scene would be sincere on their release. But I guess it would make sense, not much of a point with the things released now.......

my opinion on whether or not the release of kernel exploits actually becomes a question, for those who may already have the kernel exploits they can use it to play pirated games, especially for users who have a psp that can be hacked. but what about the PSP Go users who buy a psp where they are above expectations given by one of hacker after two days the console came out? the question is what if the kernel exploits of the last firmware for the psp go on release?(sorry for my bad english)

my opinion on whether or not the release of kernel exploits actually becomes a question, for those who may already have the kernel exploits they can use it to play pirated games, especially for users who have a psp that can be hacked. but what about the PSP Go users who buy a psp where they are above expectations given by one of hacker after two days the console came out? the question is what if the kernel exploits of the last firmware for the psp go on release?(sorry for my bad english)

I think you're talking about "FreePlay's" exploit, right? Patched and was only user-mode FYI. No one ever said it was kernel mode. And I hope you're not referring to kernel exploits as just a means to pirate. The translation is a little messy so I may have misunderstood you, i apologize if there was any misunderstanding.

PSP 3000's that came with 5.70are actually PSP 4000's
New mobo? Or something else?

my opinion on whether or not the release of kernel exploits actually becomes a question, for those who may already have the kernel exploits they can use it to play pirated games, especially for users who have a psp that can be hacked. but what about the PSP Go users who buy a psp where they are above expectations given by one of hacker after two days the console came out? the question is what if the kernel exploits of the last firmware for the psp go on release?(sorry for my bad english)

I think you're talking about "FreePlay's" exploit, right? Patched and was only user-mode FYI. No one ever said it was kernel mode. And I hope you're not referring to kernel exploits as just a means to pirate. The translation is a little messy so I may have misunderstood you, i apologize if there was any misunderstanding.

okay i apologize too, but please think about psp go user like me, why until this day,and it almost a year we can't play iso or something, and i just can play homebrew, but now i will get boring about homebrew cause in my country in indonesia download game for psp is more expensive, price of the game is from 300.000 IDR until 600.000 IDR. and if we use our psp go for downgrade or hacking will brick my psp,cause now no more sony center service in indonesia so please think about us!(sorry for my bad english)

but what about the PSP Go users who buy a psp where they are above expectations given by one of hacker after two days the console came out?

I think there is a saying in English "beggers are not choosers" or something like that, which means that if you want to hack your PSP, you should start doing it yourself.

I know, it's easier said than done, but consider this: nowadays, to hack a PSP through software, you need to already have a hacked PSP.
It means ALL hackers already have at least one hacked PSP.

Now, think about it yourself: if you had a hacked PSP, would you be actively looking for exploits? The answer is: most people who have a hacked PSP don't care at all about other users. So, before asking if hackers "care" about PSP Go users, buy a hackable PSP yourself, and see if you still care about the sake of other users (not enough money? Sell your Go and buy a used Phat, you will even make money). If you do, then you are "good enough" to ask that kind of question. Otherwise, you're just egotistic, like most people (and unlike hackers).

That's what PSP hackers do on a daily basis: work for others, not for themselves, because they already have a hacked PSP. So don't think hackers "don't care" about the others. As a matter of fact, hackers probably care more about the hackable status of THE psp Go than PSP go owners themselves, who only care about the hackable status of THEIR psp go.

In other words, if you truly want the psp go to be hacked, you need to buy a hackable PSP. Ironic, isn't it? :D

You can also blame yourself for your initial choices...why did you buy a psp go in the first place? you knew it was a unhacakble system. Or, if you didn't, you should have researched more before buying.

By the way, I'm not trying to be insulting you or anything, I'm just saying that it's easy to forget that the hackers community don't owe anything to the psp scene, and that anyone who really wants to can become a hacker. Hackers don't have superpowers. Just a hackable PSP (LESS expensive than a psp go, so you can't use money as a justification for not buying one) and a brain (ships by default on most humans models).

a brain (ships by default on most humans models).

I lol'd yea, they ship the hardware by default... but 90~99% of that hardware comes pre-installed with terrible firmware, and in my case... more bad blocks than it should have.

but what about the PSP Go users who buy a psp where they are above expectations given by one of hacker after two days the console came out?

I think there is a saying in English "beggers are not choosers" or something like that, which means that if you want to hack your PSP, you should start doing it yourself.

I know, it's easier said than done, but consider this: nowadays, to hack a PSP through software, you need to already have a hacked PSP.
It means ALL hackers already have at least one hacked PSP.

Now, think about it yourself: if you had a hacked PSP, would you be actively looking for exploits? The answer is: most people who have a hacked PSP don't care at all about other users. So, before asking if hackers "care" about PSP Go users, buy a hackable PSP yourself, and see if you still care about the sake of other users (not enough money? Sell your Go and buy a used Phat, you will even make money). If you do, then you are "good enough" to ask that kind of question. Otherwise, you're just egotistic, like most people (and unlike hackers).

That's what PSP hackers do on a daily basis: work for others, not for themselves, because they already have a hacked PSP. So don't think hackers "don't care" about the others. As a matter of fact, hackers probably care more about the hackable status of THE psp Go than PSP go owners themselves, who only care about the hackable status of THEIR psp go.

In other words, if you truly want the psp go to be hacked, you need to buy a hackable PSP. Ironic, isn't it? :D

You can also blame yourself for your initial choices...why did you buy a psp go in the first place? you knew it was a unhacakble system. Or, if you didn't, you should have researched more before buying.

By the way, I'm not trying to be insulting you or anything, I'm just saying that it's easy to forget that the hackers community don't owe anything to the psp scene, and that anyone who really wants to can become a hacker. Hackers don't have superpowers. Just a hackable PSP (LESS expensive than a psp go, so you can't use money as a justification for not buying one) and a brain (ships by default on most humans models).

True :D but "beggers are not choosers" is actually beggers can't be choosers ;) but thanks for explaining that to people and hows its all done :D

Is there any patched in 6.xx kexploit than may used with MOHH exploit?

MoHH exploit is patched on 6.XX dude...

m0skit0,
i know it =) I'd like to play on 5.55 with MOHH & kexploit, but i don't have second one.
May be someone have useless in 6.xx kexploit [than may be used with MOHH exploit on 5.55]?

You said 6.XX, not 5.55 :P Also if you want to play with 5.55, why you want a 6.XX kxploit? You make no sense.

And anyways, if you're waiting someone to give you a 6.XX kxploit, then you'd better take a comfortable seat and wait around.

People these days...

any patched in 6.xx
Patched in 6.xx and not patched in 5.xx [up to 5.55].

I think this thread has outrun it's "development" discussion. @Yoti, if anyone is willing to share an obsolete exploit, I'm sure they will PM you.

Closed.